List of True Things About Elixir Logger Handlers and Backends

Dear reader, I am easily confused by loggers. For a long time, the Elixir logger was simple enough that I could live with it. But starting with version 1.15, something changed, and now I'm confused.

Luckily for me, Elixir.Logger documentation does an excellent job explaining everything. The problem is that it's a lengthy read and I need a refresher the moment I take my eyes off it.

This post is an attempt to complement the official docs by not adding more documentation, but rather by taking things out.

About Logger Handlers

• Elixir Logging is configured using logger handlers.
• A logger handler is an Erlang concept.
• The default logger handler is :logger_std_h
• Logger handlers are called in the client process.
• It is recommended that logger handlers implement something called overload protection.
• :logger_std_h does implement overload protection.
• Logger handlers are configured under your application's namespace:

  config :my_app, :logger ...
  

• The default logger handler can be configured under the :logger namespace:

  config :logger, :default_handler ...
  

• Non-default logger handlers need to be attached to your application on startup

  Logger.add_handlers(:my_app)
  

About Logger Backends

• LoggerBackends is a Hex package.
• LoggerBackends code is also included in core Elixir for backward compatibility.
• LoggerBackends was the primary logging mechanism in Elixir before version 1.15.
• LoggerBackends provides a logger handler called LoggerBackends.Handler.
• LoggerBackends.Handler implements overload protection.
• A logger backend is a concept unique to LoggerBackends.
• A logger backend is a module that can be plugged into LoggerBackends.Handler.
• All logger backends benefit from overload protection implemented in LoggerBackends.Handler.
• Logger backends run in a single separate process.
• It is possible to unknowingly use LoggerBackends via legacy configuration options.

About Extension Points

• It is very rare that you need to implement your own logger handler.
• Logger handlers can be extended using Filters and Formatters.
• It is normal to employ multiple logger handlers.
• An example of a custom logger handler use case is Sentry.LoggerHandler.
• An example of a custom logger formatter use case is the LoggerJSON suite.

┌──────┐
│ Logs │
└──┬───┘
   │
   ├───────────────────┬───────────────────┐
   │                   │                   │
   ▼                   ▼                   ▼
┌──────────────┐┌──────────────┐┌──────────────────────┐
│logger handler││logger handler││LoggerBackends.Handler│
└──────────────┘└──────────────┘└──────────┬───────────┘
                                           │
                                     ┌─────┴─────┐
                                     │           │
                                     ▼           ▼
                                ┌──────────┐┌──────────┐
                                │  logger  ││  logger  │
                                │ backend  ││ backend  │
                                └──────────┘└──────────┘

List of Questionable Advice

1. If you have a pre-1.15 Elixir app on your hands, migrate it to logger handlers.
2. Forget logger backends exist to avoid confusion.
3. Whenever you need to customize your logging stack, try doing it with filters and formatters.
4. If it doesn't work, consider remembering logger backends exist and implement your own to piggyback on built-in overload protection.
5. If you still need to implement a custom logger handler, godspeed 🫡